view this document with Notepad 800*600


                     L                ZZZZZZ         RRRRR           SSSSS
                     L                    Z          R    R         S
                     L          aaa      Z      aaa  R    R  u   u  S
                     L            a     Z         a  RRRRR   u   u  SSSSS
               XX    L         aaaa    Z       aaaa  R    R  u   u       S
              XXXX   L        a   a   Z       a   a  R    R  u   u       S
             XXXXXX  LLLLLLL  aaaaa  ZZZZZZZ  aaaaa  R    R  uuuuu  SSSSSS
             XXXXXX       
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
             XXXXXX
             XXXXXX
              XXXX        proudly presents his 5.Cracking Tutorial (29.03.1999)
               XX       What the programmers can do to protect their work better


This tutorial is (nearly) the translation of another one I've written for a national shareware
organization. I just got rid of the leading chapters "Intentions of this tutorial", "Think 
like a cracker" and the word explaination.
Some parts of this turorial were influenced by the tutorials I found on Fravia's page 
(www.fravia.org is currently down: find a mirror at www.proweb.co.uk/~greenway)

1.Things you can do fast and easy
2.The application Win-Dummy as an example what a programmer can do wrong
3.Things that are harder to code/things I wasn't able to include in my Win-Dummy story and things
  I invented writing this tutorial (I don't know if they work).

1.Things you can do fast and easy
The first thing I want to say is that every shareware program that can be upgraded to the full
version can be cracked. You cannot hide anything in a debugger or disassembler. If you search
long enough you WILL find the crack. So you cannot prevent your program from being cracked, but
you can try to bore the cracker that he doesn't keep on trying to crack the target. The following
tips are useful to reach this.

At first a warning: Don't use any commercial protection scheme, because they are damn bad and
all cracked, anyway. The same with EXE packers. While you unpack the files you get something to
eat so they don't really disturb.

Let's start with the smaller, easier things, you can do with a minimum of programming work. At
first you should never use functions where the name of the function reveals what they do. For
example the company Ulead that calls their functions often something like IsFullVersion. Guess
what this function does. I like IsValidSerial, too. ;-)

The same for the entries in INI files or the windows registry. For example BCM Diagnostics. This
tool manages a value in the registry IsRegistered (or something like that). If this value is 0
the program starts as shareware, is the value 1 the program is the full version. One-minute crack
with Registry Monitor.

The coders of Pixel3D coded without using their brain, too. At first I thought they have done
everything right, to make my life harder, but then I tried something I never read anywhere 
before. I deleted all registry values, Pixel3D manages and restarted it. Now I cracked away
all "Cannot read data from registry" messages and Pixel3D started as full version. This should
show you: Whenever something unpredictable happens, your program must start as shareware. The
honest user can register it again.

Another way to react if anything unpredictable happened, is to delete important values or files.
The program should have to be reinstalled. Another way is to reboot the computer. This actions
you should only use, if you are 100% sure that the part of the program that checks if something
strange happened works absolutely correct, or you could make honest buyers angry.

If you write a helpfile you should in no way mention anything about the registration code.
The worst thing I ever saw was a helpfile where the structure of the code was mentioned:
XXXXX-XXXX-XXX. But the programmer was silly enough to make another heavy mistake. If you
enter 0 as name the valid code is 00000-0000-000. Seems the programmer uses only multiplication
to calculate the valid serial.
Best thing to do is to make wrong statements about the serial in the helpfile. Example: Once
I had a target that said in is helpfile something like "If you register ??? you get a keyfile
called keyfile.dat that upgrades your shareware version to the full version. Later I found out
that the name of the keyfile was completely different.

Don't "hardcode" important strings. They are always the first waypoint for a cracker. You better
use something like char(65)+char(66)... 
Especially deadly are MessageBoxes and textareas in nag-screens. But you as a programmer can turn
this thing around. Hide the important strings and declare somewhere in the program real strings 
with the same value as the hidden strings. Or use strings that could be from your compiler like
GetWindowText/EnableMenuItem... This can confuse some disassemblers and they will produce 
confused code.

2.The application Win-Dummy as an example what a programmer can do wrong
So far to the easy things. This chapter is about the imaginary application Win-Dummy. I create
an application that behaves like the average shareware program: nag-screen/reg-code/time limit/
restrictions...
Let's start the program. *BANG* a nag-screen pops up. This is no too good idea. If the program
can be updated to the full version with a serial or keyfile or whatever there must be a
check if the serial/keyfile... is valid. Crackers start usually by looking at the strings that
appear in the nag-screen, so it would be better to use BMP pictures as nagscreen, but only if
you program your own functions to show them. If you use the API functions there are no security
improvements, because they can easily be located.
Back to the nag-screen. To check if the program is shareware it has to read a value from a file
or the windows-registry. This value can be something like:

IsRegistered=0/1

or 

Name: XXX
Code: YYY

If the programmer used the first solution it is easy to get rid of the nag-screen. Did he choose
the second one the code must be calculated in front of the nag-screen. So the cracker can easily
find the calculation function that is perfectly hidden in the other parts of the program.

Normally a nag-screen is useful for showing the user how much time he has left in his evaluation
period. Using something like GetSystemDate is not the best solution for the time calculation.
The user can easily turn back the windows clock and the program will never expire. At least you
programmers should check if something strange happened (time jumps or something like that).
A much more effective way to get the current date is the file SYSTEM.DA0. This file is updated
every reboot and has always the correct date (if the user does have the correct date when he 
starts his computer).
Another example: To make some programs never expire, you must do this: Add 10 years to your 
system date, install the application and switch back the date. Start the application and you
have more than 3600 days left for testing. (Until the expiration there should be a never version
of the target ;-))

OK, click away the nag-screen. Like in most programs you see UNREGISTERED in the window caption.
One more chance for the cracker. If you calculate the code you shouldn't change the window 
caption and other restrictions at once, because the calculation can be easily found in this way.
Better change the caption some hundred lines later. (Note: Are there any programs that check
if they are full versions by checking the window title? If there are some, the programmer has
chosen the wrong job,)

Looking around in Win-Dummy you we recognize that some functions are not available in the share-
ware version. Some buttons and menus are gray or a messagebox pops up saying "Only in full 
version". At first define all menus during runtime, because predefined menus that are stored in
the EXE file can easily be changed with a ressource workshop.
Anyway, the "graying" of menus is a mistake. Somewhere in the program must be the function
EnableMenuItem. This function doesn't appear to often, so it can easily be located. It is better
to create the menus at runtime, so the cracker doesn't know the name of them (watch at the help-
file). 

Now we start to figure out the serial:
The first thing a cracker should say is: HELL, WHERE IS THE INPUT BOX ???
The best thing is a hidden Register window that can be enabled with a key combination. This can
be something like [CTRL]+[ALT]+[DEL] or better [CTRL]+[D].

Now two of my beloved tricks I use in some crackmes. At first call the code-box "Enter name here"
and the name box "Enter code here". The cracker has to figure this out, first.
The second trick is: Create two inputareas. A name-area and a code-area. One "Check code" button
below them. The code is checked, if the values of the two are changed. If you hit the OK-Button,
the "Wrong Code" message always appears.

Calculating the code:
At first you have to declare some variables. The program allocates memory where it can store the
value of the variables and so on for the next variables. OK you should declare the variable for
name, entered code and correct code should be declared far away from each other so the cracker
can't get the code by memory dumping. 

You should never calculate the hole serial. Better calculate a part of the serial and compare it
with the entered serial. Then calculate the next one and compare it...
To calculate the serial you should use some KB of mathemathical instructions to confuse the 
cracker comletely. The risk of a keygen is nearly 0 then. 
Using giant loops where the cracker cannot get that he is in one are good to bore the cracker 
to hell. This loop 1000 times and the cracker wastes hours of time just tracing through a loop.
I like fake serial calculations, too. Just code 15 different calculation schemes, where only
one scheme gives you a valid serial.
Calculating not with variables, but with pointers is hard to get, too and the values are nowhere
stored in the RAM.
After the calculation set the variables that contained the valid code to 0 or "" that the cracker
can't find the correct code by memory dumping.

If you show a "Wrong code" message, then check the code twice. One time with the message and
one time without it. 

Silly is when you write the valid serial to the file instead of the entered serial. Just jump
over the IsValid check and the correct serial is written to the file (Goldwave) or a valid
keyfile is created (HexWorkshop).

3.Things that are harder to code/things I wasn't able to include in my Win-Dummy story and things
  I invented writing this tutorial (I don't know if they work).
Then following things are hard to code. Sometimes to hard for a shareware program.

1.A single CRC check is most time easily cracked. Better make one in the EXE file that checks if
  a DLL file is valid and the other way.
2.Make the name of the keyfile depend on the serial and point to that keyfile from the windows
  registry if the valid serial is entered.
3.Make the input box look like the window so that nobody can see it who doesn't know that it
  exists.
4.Let the last char of the valid serial be a "." - They are hard to see in a serial. Example:

OFFSET      HEX-CODE DES PASSWORTS         PWD IN ASCII 
XXXX:XXXX   00 00 00 00 00 00 00 00        ........ 
XXXX:XXXX   65 66 67 68 69 70 71 19(?)     ABCDEFG. 
XXXX:XXXX   00 00 00 00 00 00 00 00        ........ 

The last point in line two is part of the serial, not of the ASCII 00.

5.Use "-" in your password, but not regularly, but like X-XXXX-XXX-XX. And calculate the serial
  without the "-", but check if they exist.

6.Use control variables to check if a CALL was executed correctly.

7.If you code with Delphi or C++ Builder you can choose the predefined components like Label to
  hide important string, because they are saved encrypted.

8.Make the serial depend on the hardware configuration.

9.Check if the name can be valid: ][ce, LaZaRuS [hf], ED!SON, +wAj., _mammon can never be real
  names.


BTW
Hope my tutorial was helpful for you and see you again in my next tutorial. 
     
Greets to: Fravia+, tKC, ED!SON, Moral Insanity, The Sandman, Eternal Bliss, DaVinci and 
all [hf] members

All Tutorials by LaZaRuS [hf]
      
#|  date  |   name           |version|W32Dasm|Soft-Ice|kind of crack            |
-|--------|------------------|-------|-------|--------|-------------------------|
1|20.01.99|Jaylock           |1,0,0,1|  (X)  |   (X)  |serial#                  |
2|31.01.99|Goldwave          |4.02   |  (X)  |   (X)  |serial#,nag-screens      |
3|28.03.99|AxMan             |3.00   |  (X)  |   (X)  |serial#,remove date-limit|
4|29.03.99|C++Builder Strings|       |  (X)  |   (X)  |how to find strings in   |
 |        |                  |       |       |        |C++ Builder that are not |
 |        |                  |       |       |        |hardcoded                |
5|29.03.99|Better Protection |       |       |        |How to protect shareware |
 |        |                  |       |       |        |better against crackers  |

     
LaZaRuS [hf]
Visit Hellforge at http://members.xoom.com/hell_crack for more tutorials and high quality
cracking links.
If you want to mail me: lazarus666@gnwmail.com